Methods and apparatus for performing authentication and decryption

ABSTRACT

Methods and apparatus are provided for performing authentication and decryption operations. A record including multiple encrypted blocks is received. An encrypted block in the record is extracted and decrypted first in order to obtain context information for performing authentication operations. Each remaining block is then decrypted and authenticated by using the available context information. Authentication operations can be performed without having to wait for the decryption of all of the blocks in the record.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.11/491,166, filed Jul. 24, 2006, now allowed as U.S. Pat. No. 7,764,788,titled “Methods and Apparatus for Performing Authentication andDecryption,” which is a continuation of U.S. application Ser. No.10/160,335, filed May 31, 2002, now U.S. Pat. No. 7,082,534, issued onJul. 25, 2006, each of which is incorporated by reference herein in itsentirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present application relates to cryptography operations. Morespecifically, the present application relates to methods and apparatusfor efficiently performing authentication operations on a block in arecord as soon as the block is decrypted.

2. Background Art

Many secure communications protocols, for example Secure Sockets Layer(SSL) and Transport Layer Security (TLS), specify that data be bothencrypted for data privacy and authenticated for integrity and sourceverification. Conventional software and hardware designs for performingdecryption and authentication operations are inefficient. One techniquefor performing authentication and decryption entails using softwaretechniques to receive a record and decrypt the entire record. Upondecrypting the entire record, authentication operations are thenperformed on each of the decrypted blocks in the record. However, manyinefficiencies are introduced by having to read and process the samedata multiple times. Many firmware and hardware techniques share similarinefficiencies.

Software, firmware and hardware techniques for performing decryption andauthentication operations, such as DES, RC4, AES, MD5 and SHA1operations used in secured sessions have been inefficient and resourceintensive. Secured sessions, authentication operations, and decryptionalgorithms are described in Applied Cryptography, Bruce Schneier, JohnWiley & Sons, Inc. (ISBN 0471128457), NIST Federal InformationProcessing Standard FIDS-197 (AES), Internet Engineering Task Force(IETF) Request for Comments Standard RFC2246 (TLS), and SSL and TLS:Designing and Building Secure Systems, by Eric Rescorla (ISBN0201615983), the entireties of which are incorporated by reference forall purposes.

It is therefore desirable to provide methods and apparatus for improvingdecryption and authentication processing with respect to some or all ofthe performance limitations noted above.

BRIEF SUMMARY OF THE INVENTION

Methods and apparatus are provided for performing authentication anddecryption operations. A record including multiple encrypted blocks isreceived. An encrypted block in the record is extracted and decryptedfirst in order to obtain context information for performingauthentication operations. Each remaining block is then decrypted andauthenticated by using the available context information. Authenticationoperations can be performed without having to wait for the decryption ofall of the blocks in the record.

In one embodiment, a method for performing authentication and decryptionis provided. A first block in a record comprising a plurality ofencrypted blocks is decrypted. The first block includes contextinformation for deriving authentication values. A second block in therecord comprising the plurality of encrypted blocks is decrypted. Anauthentication value associated with the second block is derived byusing context information before the remaining blocks in the record aredecrypted.

In another embodiment, a cryptography accelerator is provided. Thecryptography accelerator includes interface circuitry, cryptographycircuitry, and authentication circuitry. The interface circuitry isoperable to receive a record including a plurality of encrypted blocks.The cryptography circuitry is coupled to the interface circuitry. Thecryptography circuitry is operable to receive the record from theinterface circuitry and decrypt a first block in the record. The firstblock includes context information. The authentication circuitry isoperable to derive an authentication value associated with a secondblock in the record by using context information obtained upondecrypting the first block. The authentication value is derived before athird block in the record is decrypted.

These and other features and advantages of the present invention will bepresented in more detail in the following specification of the inventionand the accompanying figures, which illustrate by way of example theprinciples of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

The invention may best be understood by reference to the followingdescription taken in conjunction with the accompanying drawings, whichare illustrative of specific embodiments of the present invention.

FIG. 1 is a diagrammatic representation of a system that can use thetechniques of the present invention.

FIG. 2 is a diagrammatic representation of an integrated circuitcontaining processing cores for performing authentication andcryptography operations.

FIG. 3 is an interaction diagram showing a sequence in which thetechniques of the present invention can be applied.

FIG. 4 is a diagrammatic representation showing data and records.

FIG. 5 is a diagrammatic representation showing the structure of arecord.

FIG. 6 is a diagrammatic representation showing cipher block chainingused to process blocks in the record.

FIG. 7 is a flow process diagram showing a technique for performingauthentication and decryption.

FIG. 8 is a flow process diagram showing another technique forperforming authentication and decryption.

DETAILED DESCRIPTION OF THE INVENTION

The present application relates to implementing a cryptographyaccelerator. More specifically, the present application relates tomethods and apparatus for providing a cryptography accelerator capableof performing simultaneous decryption and authentication.

Reference will now be made in detail to some specific embodiments of theinvention including the best modes contemplated by the inventors forcarrying out the invention. Examples of these specific embodiments areillustrated in the accompanying drawings. While the invention isdescribed in conjunction with these specific embodiments, it will beunderstood that it is not intended to limit the invention to thedescribed embodiments. On the contrary, it is intended to coveralternatives, modifications, and equivalents as may be included withinthe spirit and scope of the invention as defined by the appended claims.

For example, the techniques of the present invention will be describedin the context of SSL or TLS using the DES, AES, and RC4 encryptionalgorithms and the SHA-1 and MD5 authentication algorithms. However, itshould be noted that the techniques of the present invention can beapplied to a variety of different authentication and cryptographyoperations for cryptography processing in general. In the followingdescription, numerous specific details are set forth in order to providea thorough understanding of the present invention. The present inventionmay be practiced without some or all of these specific details. In otherinstances, well known process operations have not been described indetail in order not to unnecessarily obscure the present invention.

FIG. 1 is a diagrammatic representation of one example of a processingsystem 100 in accordance with an embodiment of the present invention. Asshown in FIG. 1, the present invention may be implemented in astand-alone cryptography accelerator 102 or as part of the system 100.Any logic, mechanism, or device operable to perform encryption,decryption, and/or authentication operations is referred to herein as acryptography accelerator. In the described embodiment, the cryptographyaccelerator 102 is connected to a bus 104 such as a PCI bus via astandard on-chip PCI interface. The processing system 100 includes aprocessing unit 106 and a system memory unit 108. The processing unit106 and the system memory unit 108 are coupled to the system bus 104 viaa bridge and memory controller 110.

Although the processing unit 106 may be the central processing unit(CPU) of a system 100, it does not necessarily have to be the CPU. Itcan be one of a variety of processors in a multiprocessor system. In oneexample, a LAN interface 114 is provided to couple the processing system100 to a local area network (LAN) to allow packet receipt andtransmission. Similarly, a Wide Area Network (WAN) interface 112 canalso be provided to connect the processing system to a WAN (not shown)such as the Internet. The WAN interface manages in-bound and out-boundpackets to allow automatic decryption and authentication processing.

According to various embodiments, the cryptography accelerator 102 is anapplication specific integrated circuit (ASIC) coupled to the processor106. The cryptography accelerator 102 can also be a programmable logicdevice (PLD), field programmable gate array (FPGA), or other devicecoupled to the processor 106. According to specific embodiments, thecryptography accelerator 102 is implemented either on a card connectedto the bus 104 or as a standalone chip integrated in the system 100.

In other embodiments, the cryptography accelerator 102 itself isintegrated into the processing core of a CPU of system 100, such as thatavailable from Tensilica Corporation of Santa Clara, Calif. or MIPSTechnologies of Mountain View, Calif. In another embodiment, techniquesand mechanisms of the present invention are integrated into a CPU suchas a CPU available from Intel Corporation of San Jose, Calif. or AMDCorporation of Sunnyvale, Calif. By implementing cryptographyaccelerator functionality entirely on the processor 106, a separate cardor chip in the system 100 is not needed. In still other embodiments, theprocessing system 100 including the cryptography accelerator 102 isimplemented as a system on a chip (SOC). The network interfaces, memory,processing core, and cryptography accelerator functionality are providedon a single integrated circuit device.

The cryptography accelerator 102 is capable of implementing variousnetwork security standards, such as SSL and TLS, which provideapplication-transparent encryption and authentication services fornetwork traffic. It should be noted that all references to SSL alsoapply to TLS.

Network security standards such as SSL provide authentication throughthe use of hash algorithms and encryption through the use of encryptionalgorithms. Two commonly used hash algorithms are MD5 and the SecureHash algorithm (SHA-1). Other hash algorithms such as MD4 and MD2 arealso available. Two commonly used encryption algorithms are DES and RC4.Other encryption algorithms such as triple DES and AES, are alsoavailable. Authentication and encryption algorithms are described inApplied Cryptography, Bruce Schreier, John Wiley & Sons, Inc. (ISBN0471128457), incorporated by reference in its entirety for all purposes.Even though many network security standards apply the same hashalgorithms, different approaches are taken toward applying the hashalgorithms to the actual authentication computation.

Protocols such as SSL specify performing authentication operations ondata in a data sequence to derive an authentication code. The data andthe authentication code are then encrypted for transmission as anencrypted data sequence. An entity receiving the encrypted data sequencetypically processes the data by decrypting the sequence. After theentire sequence is decrypted, the original data sequence and theauthentication code are obtained. Authentication operations are thenperformed on the data sequence to determine if the authentication codecorresponds with the data sequence.

However, many techniques for performing SSL operations require that thedata be processed multiple times. In one example, an encrypted datasequence is decrypted in a first pass. It should be noted thatauthentication operations can not be performed first or simultaneouslyhere because the authentication operations require decrypted data and adecrypted authentication code. Authentication operations are performedin a subsequent pass after the data sequence is decrypted in order toderive authentication values that are checked against an authenticationcode. These techniques require that the data sequence be processedseveral times, leading to inefficient and redundant processing. Typicalsoftware and hardware implementations fail to efficiently decrypt andauthenticate a data sequence in a single pass.

The techniques of the present invention, however, provide not only for acryptography accelerator configured for efficient decryption andauthentication processing, the techniques of the present inventionprovide for simultaneous authentication and decryption by selectivelydecrypting and authenticating portions of a data sequence at a time. Byintelligently decrypting portions of a data sequence, in a specificorder, efficient simultaneous decryption and authentication of portionsof a data sequence is enabled.

FIG. 2 is a diagrammatic representation of one example of a cryptographyaccelerator 201. The cryptography accelerator 201 includes an interface203 connected to a host such as an external processor. According tovarious embodiments, the interface 203 receives information from thehost for processing and sends information to the host when processing iscompleted. In one example, encrypted data associated with an SSLexchange is received through the interface. The interface 203 includes ascheduler for determining whether to send data blocks to variousprocessing engines such as authentication engine 217 and cryptographyengine 209. In one embodiment, encryption engine 209 includes componentssuch as a DES engine 221 and an AES engine 223. An authentication engine217 includes components such as MD5 engine 225 and SHA1 engine 227. Itshould be noted that a cryptography accelerator 201 can include othercomponents as well, such as a public key engine or cores for performingother authentication and encryption algorithms.

According to various embodiments, components for performing operationssuch as XOR operations are also included in the cryptographyaccelerator. In one example, an XOR component is included in theauthentication engine so that SHA-1 and MD5 processed data can becombined together.

According to various embodiments, the techniques of the presentinvention are used in a secured session. Any message exchange sequencebetween two parties using both authentication and encryption and commonsession information known to both parties is referred to herein as asecured session. In one example, a secured session is an SSL session. Asecured session typically includes a handshake phase and a data exchangephase. A handshake phase often includes a key exchange sequenceestablishing common information, such as a shared key, for thetransmission of data during the data exchange phase between two parties.Any mechanism involving exchanging information to establish a securedsession between two entities is referred to herein as a handshake phase.According to various embodiments, the techniques of the presentinvention apply to the handshake phase.

FIG. 3 is a transaction diagram showing one example of a handshake phaseassociated with SSL. A wide variety of sequences associated withhandshake phases are available. At 311, the client 301 transmits amessage with a security enable parameter to a server 303. In oneembodiment, the authentication message contains an identifier such as auser name or an authentication identifier that allows the receiver toselect an authentication mechanism out of a possible set of mechanisms.In another embodiment, the client sends an SSL version number, ciphersettings, and client random information to the server 303. Server 303mayor may not already have information associated with the client. Theserver 303 identifies the security enable parameter along with anyclient proposed algorithms and proposes algorithms for encryption, forauthentication, and for exchange or agreement of the cryptographic keys.

According to various embodiments, the server sends the server's own SSLversion number, cipher settings, and server random information to theclient 301. In one embodiment, the server also sends its certificate. Acertificate may be a hash of a combined public key and identifierassociated with the server encrypted with a trusted third party key. Ifthe client is requesting a server resource that requires clientauthentication, the server at this point can also request to clientcertificate. According to other embodiments, protocol version, sessionID, cipher suite, and compression method are exchanged along with clientrandom information and server random information.

At 317, client 301 uses the information sent by the server toauthenticate the server. The client then generates a pre-master secretfor the session, encrypts the pre-master secret with the server's publickey obtained from the server certificate, and sends the encryptedpre-master secret to the server at 321. In one embodiment, the clientcomputes a pre-master secret using server random information.Information such as a pre-master secret or a client random sequence usedto derive session keys is referred to herein as key generationinformation. In one example, a pre-master secret is used by both theserver and the client to derive a master secret which is then usedsubsequently to derive session keys. Any intermediate information usedto derive session keys from key generation information is referred toherein as master secret information.

According to various embodiments, master secret information is nottransmitted over the network during a handshake phase but is insteadderived independently by both a client entity and a server entity. Ifthe server requested client authentication, the client signs a piece ofdata that is unique to this handshake and known by both the client andserver and sends both the signed information and the client's owncertificate to the server. According to various embodiments, the clientsigns a piece of data unique to the handshake by performing a hash.

According to various embodiments, the server 303 at 325 attempts toauthenticate the client if client authentication was requested. If theclient can not be authenticated, the session is terminated. If theclient can be authenticated, the server 303 uses the key generationinformation from the client to generate session keys. In one example,the server 303 uses its private key to decrypt the pre-master secret.Both the server 303 and the client 301 use key generation informationsuch as the pre-master secret to generate a master secret andsubsequently to generate the session keys.

In one embodiment, the cryptography accelerator generates a clientencryption key, a server encryption key, a client authentication key,and a server authentication key. At 327, the session keys generated atboth the client and the server are used to establish the secure session.According to various embodiments, cryptography accelerators associatedwith both client 301 and server 303 derive keys based on the selectedalgorithm. According to various embodiments, the session keys can beused for communications between client 301 and server 303. It should benoted that a variety of different authentication sequences andcommunication sequences in general can use the techniques of the presentinvention. For example, only a single session key may be generated insome instances.

At 331, client 301 sends handshake information to the server 303. Anyinformation transmitted for determining that the session keys generatedat the server and the session keys generated at the client are the sameset of keys is referred to herein as handshake information orverification information. In one example, a server 303 receives from theclient 301 handshake information including a hash of the session keyscombined with other key generation information. The server 303 thencalculates client verification information using the session keys itgenerated. If the handshake information corresponds with the clientverification information generated at the server, verification iscompleted. Information generated by the server for comparison withhandshake information sent from the client to determine that the clienthas the correct set of session keys is referred to herein as handshakeinformation, client verification information, or client finishedinformation.

At 333, the server typically decrypts any message associated with clientverification information received from the client entity 301 andcompares the decrypted message with the generated client verificationinformation to determine that the client verification informationmatches. The server then typically issues a function call to acryptography accelerator to generate a server verification message.

Information generated by a server and sent to a client to determine thatthe server has the correct set of session keys is referred to herein ashandshake information, server verification information or serverfinished information. It should be noted that in the aboveimplementation, a master secret is never transmitted over the network.Instead, both network entities use derivatives of the pre-master secretto generate the session keys and other cryptographic information usedfor secure transmission. Both the master secret and the session keysneed not ever be transmitted over the network.

It is contemplated that a cryptography accelerator can be used in anynetwork entity including client and server entities. It should be notedthat the handshake sequence shown in FIG. 3 is only one example of asequence that can use the mechanisms and techniques of the presentinvention. In one example, both server and client can access keygeneration information from a third party source in order to deriveinformation for a data exchange. In another example, client randomnumbers may be included in a client proposed algorithm message insteadof a key generation information message.

As noted above, a secured session typically includes a handshake phaseand a data transfer phase. During a handshake phase, network entitiesare authenticated and cryptographic keys are exchanged. Data transfertypically occurs after the handshake phase is completed. Datatransmitted in a secured session is generally broken up into fragments.FIG. 4 is a diagrammatic representation showing one example of thestructure of fragmentation and protection. It should be noted that thefragmentation for a secured session is typically separate from thefragmentation of data for transmission as packets. That is, one or morefragments mayor may not correspond to one or more packets.

According to various embodiments, a data sequence 401 is broken up intoa series of fragments. Each fragment is protected individually. Areceiver of the fragment is able to verify and authenticate eachfragment. According to various embodiments, data sequence 401 is splitinto data fragment 411 and data fragment 413. Authentication operationsare then performed on data fragment 411 and data fragment 413. In oneexample, hash operations corresponding to MD5 or SHA1 operations areperformed on data fragments 411 and 413 to derive authentication codes417 and 419 respectively. Authentication codes 417 and 419 typicallyhave a fixed length depending on the specific protocol used. In variousembodiments, an authentication code 417 is derived by performing hashoperations on portions of data fragment 411 sequentially. In oneexample, information from the Record Header 421 along with positionalinformation (e.g., a sequence number) and the entire data fragment 411are hashed to derive a sixteen or twenty byte authentication value inauthentication code 417. In another examples, a non-fixed number ofbytes and other information are used to derive the authentication code.

Portions of the authentication code are referred to herein asauthentication values. After the authentication code 417 correspondingto fragment 411 is determined, padding and other information can beadded to the data fragment. Both the data fragment and theauthentication code are then encrypted to derive the encrypted data andauthentication code 427. Algorithms such as DES, AES, and RC4 are usedto encrypt the data and the authentication code 427. In manyimplementations, the data, the authentication code, and padding are allencrypted. This is the case with SSL, for example.

A record header 421 is then attached to the encrypted data andauthentication code 427 to create a record. An entity including aheader, encrypted data, an authentication code, and padding is referredto herein as a record. According to various embodiments, the encrypteddata and authentication code along with the padding has a length equalto a multiple number of fixed sized blocks. A record header 421 containsinformation such as the length of the record 431, the type of thecontent, and information about the protocol such as the version of theprotocol used. The length typically allows the receiver to know how manybytes to read before processing the record and protocol informationallows for the receiver to check to ensure that he supported protocol isbeing used.

FIG. 5 is a diagrammatic representation detailing one example of arecord. The record header 503 includes information on the total recordlength 531. The record payload 535 includes data of 505, authenticationcode 507, and padding 509. According to various embodiments, theencrypted payload is equal in length to a multiple number of fixed sizedblocks 541, 543, 545, and 547. In order for the record payload length toequal the length of a multiple number of fixed sized blocks, padding 509is added to the data and authentication code. One reason why the recordpayload 535 is equal in length to a multiple number of fixed sizedblocks is that various block cipher algorithms encrypt and decrypt afixed amount of data at a particular time. That is, a data block of aparticular size is required as an input in block cipher algorithms.Stream cipher algorithms on the other hand do not require any particularfixed sized input.

Context information such as padding length 519 is included to allow areceiver to determine the amount of data to disregard after decryptionand to allow a receiver to perform authentication operations.Information used to calculate authentication information is referred toherein as context information. Some examples of context informationinclude a message authentication code secret field, a protocol specificbyte code, a sequence number associated with the secured session, aprotocol type, a data length, and message data. In one example, a datalength 537 is required as an input along with data in order to calculateauthentication values corresponding to an authentication code 507.However, the data length 537 can not be determined before the recordpayload 535 is decrypted. Consequently, typical implementations entaildecrypting the entire payload 535 first to determine the padding length533.

By knowing the total length 531, the padding length 533, and thestandard length of an authentication code 507, the data length 537 canbe determined. Upon determining the data length 537, authenticationoperations are performed on data blocks 541 and 543. It should be notedthat padding 509 and context information is typically included in therightmost block 547 of a record. The authentication code 507 is includedin either of the rightmost block 547 or in the rightmost block 547 andin the block next to rightmost block 545. The block in a recordphysically furthest away from the record header 503 is referred toherein as the rightmost block. The block physically closest to therecord header 503 is referred to as the leftmost block. As used herein,a first block or a second block can refer to any block in a record.

Block cipher algorithms operate on blocks of data and blocks ofencrypted data. In one example, block cipher algorithms operate on ablock of ciphertext to output a block of plaintext. Stream ciphers onthe other hand, operate on streams of plaintext and ciphertext severalbits or bytes at a time. With a block cipher algorithm, the same datawill always output the same encrypted data block when a common key isused. With a stream cipher, however the same data bit or byte willencrypt to different encrypted bits or bytes every time the data isencrypted. In order to reduce the certain predictability a block cipheralgorithms, mechanisms such as cipher block chaining are used.

Cipher block chaining adds feedback to a block cipher. That is, theinformation related to the encryption of a first block is fed back intothe encryption of a second block. Information related to the decryptionof a first block is input into the decryption of a second block. Eachencrypted or decrypted block is dependent not just on the data blockthat generated it but also on all previous data blocks. In cipher blockchaining, data is XORed with the previous encrypted block before thedata is decrypted.

FIG. 6 is a diagrammatic representation showing one example of cipherblock chaining that can be used during decryption of a record. Encryptedblock 611 is passed to decryption circuitry 621. The output ofdecryption circuitry 621 is XORed with an initialization vector 651 toproduce a plain text block 641. According to various embodiments, theinitialization vector is a sequence of random or pseudo random datashared by an entity encrypting the data and the entity decrypting thedata. In one example, a client encrypting the data using cipher blockchaining uses a randomly generated initialization vector. The clientthen sends the initialization vector along with the encrypted data to areceiver. The receiver then decrypts the data using cipher blockchaining and the transmitted initialization vector. By usinginitialization vectors, identical plain text messages encrypt todifferent cipher text messages.

According to various embodiments, the encrypted block 611 is also passedto XOR component 633. Encrypted block 613 is decrypted using decryptioncircuitry 623 and combined with the encrypted block 611 at XOR component633. The results of the XOR combination is plain text block 643.Encrypted block 613 is also passed to XOR component 635. Encrypted block615 is passed to decryption circuitry 625. The output of decryptioncircuitry 625 is XORed with encrypted block 613 to produce plain textblock 645. In typical implementations, all of the encrypted blocks in arecord are decrypted using cipher block chaining. After all of theencrypted blocks are decrypted, authentication operations are thenperformed on each decrypted block. However, decrypting using cipherblock chaining and then subsequently performing authenticationoperations require that plain text blocks 641, 643, and 645 be storedtemporarily and handled again later when context information in therightmost block is determined.

As noted above, authentication operations can not be performed untilcontext information is extracted from a rightmost block. Consequently,decryption and authentication operations can not be performedsimultaneously. This reduces the speed of decryption and authenticationand increases the need for extra memory and buffer space to store plaintext blocks temporarily. According to various embodiments, thetechniques of the present invention contemplate decrypting one or morerightmost blocks in a data stream in order to acquire contextinformation and an authentication code first before other blocks aredecrypted. By acquiring context information and authentication valuesfirst, the context information and authentication values can be used toperform authentication operations as each plain text block is produced.In one example, context information and an authentication code areincluded in plain text block 645.

Encrypted block 613 and 615 are used to obtain plain text block 645. Nowthat the context information and authentication code are obtained,encrypted block 611 can be decrypted and combined with an initializationvector 651 to obtain plain text block 641. As soon as plain text block641 is obtained, authentication operations can be performed on the plaintext block 641 to verify that the block corresponds with theauthentication code in plain text block 645. It should be noted thatauthentication operations can be performed on the plain text block 641before the other encrypted blocks are decrypted. Anything that occursbefore the resulting plain text block is determined is referred toherein as occurring before decrypting the block or before the block isdecrypted.

In one example, authentication operations on plain text block 641 areperformed before the plain text block 643 is determined. In otherexamples, several plain text blocks may be acquired beforeauthentication operations are performed on the plain text blocks.Nonetheless, the authentication operations are still performed beforeother blocks are decrypted. By performing authentication operationsimmediately upon determining the plain text block, efficiency isenhanced and no added buffer is needed for storing additional plain textblocks.

FIG. 7 is a flow process diagram showing a typical technique forperforming authentication and decryption. At 701, a record associatedwith a session is obtained. According to various embodiments, the recordis any record exchanged during the data exchange phase of a securedsession. At 703, all blocks in the record are decrypted. At 705, thedecrypted blocks are output. At 707, context information is obtained. Inone example, context information is a padding length included in thelast byte of the rightmost block in a record. Using the contextinformation, authentication operations are performed on all blocks inthe record. If it is determined at 711 that the authentication valuesdetermined correspond to the authentication code in the record, the datais output as decrypted and authenticated. However, if the authenticationvalues determined by using the authentication operations do notcorrespond to the authentication code contained in the record, a failureis noted.

FIG. 8 is a flow process diagram showing another technique forperforming authentication and decryption. At 801, a record associatedwith a session is obtained. At 803, a block containing contextinformation such as the padding length is decrypted. In manyimplementations, the block containing context information is therightmost block in a record farthest from the header. It should be notedthat a header is typically not encrypted. In one example, cipher blockchaining entails decrypting the rightmost block by using both therightmost block and the block prior to the rightmost block in a record.

At 805, context information is extracted and used to initialize anauthentication engine at 807. In one example, an authentication enginerequires entries such as the length of the actual data in a record inorder to perform authentication operations. At 809, a data block such asthe leftmost data block is decrypted. Instead of decrypting all the datablocks in a record, the decrypted data block is used to calculate anauthentication value. The decrypted block is then output at 813. At 815it is determined whether there are any remaining encrypted blocks in therecord. If there are remaining encrypted blocks, the next data block isdecrypted and an authentication value is calculated using the contextinformation. After all of the encrypted data blocks are decrypted andafter all authentication values are calculated, it is determined whetherthe authentication values correspond to an authentication code includedin the record. In one embodiment, the authentication code is included inthe rightmost block or the block next to the rightmost block in arecord.

If the authentication values correspond to the authentication code at821, the data has been successfully decrypted and authenticated. If theauthentication values do not correspond, a failure is indicated. Itshould be noted that the various steps shown above do not necessarilyhave to be performed in the particular order specified. In one example,authentication values can be compared with an authentication code assoon as authentication values are calculated at 811. In other examples,several data blocks may be decrypted before authentication values arecalculated.

While the invention has been particularly shown and described withreference to specific embodiments thereof, it will be understood bythose skilled in the art that changes in the form and details of thedisclosed embodiments may be made without departing from the spirit orscope of the invention. It is therefore intended that the invention beinterpreted to include all variations and equivalents that fall withinthe true spirit and scope of the present invention.

What is claimed is:
 1. A method for performing decryption andauthentication using a processor, the method comprising: decrypting afirst block in a record comprising a plurality of encrypted blocks, thefirst block including a padding length; determining a data length of therecord using the padding length; decrypting a second block in therecord; deriving an authentication value, associated with the secondblock, using the data length; and performing an authentication operationon the second block, using the authentication value and the data length,before a third block is decrypted.
 2. The method of claim 1, wherein theauthentication value comprises a portion of an authentication codeassociated with the entire record.
 3. The method of claim 2, furthercomprising: decrypting each additional block in the record; deriving anadditional authentication value associated with each additional block;and determining whether the authentication code corresponds with theauthentication value and the additional authentication values.
 4. Themethod of claim 2, wherein the determining the data length of the recordfurther comprises: determining the data length using a total length ofthe record and the authentication code.
 5. The method of claim 3,further comprising determining that an error has occurred if theauthentication code does not correspond with the authentication valueand the additional authentication values.
 6. The method of claim 1,wherein the first block and the second block are decrypted based onpredetermined positions in the record of the first block and the secondblock.
 7. The method of claim 1, further comprising simultaneouslydecrypting and authenticating the second block and each or a pluralityof additional blocks in the record, using a plurality of additionalauthentication values, wherein each additional authentication value isassociated with a respective one of the each additional blocks.
 8. Amethod, comprising: dividing, using a processing device, a data sequenceinto a plurality of data fragments; storing, using the processingdevice, context information for a first data fragment in a first blockof the first data fragment; deriving, using the processing device, anauthentication code for the first data fragment, using the contextinformation; storing, using the processing device, the authenticationcode in a second block of the first data fragment, wherein theauthentication code comprises a plurality of authentication values,wherein each authentication value is associated with a respective one ofa plurality of blocks of the first data fragment, and wherein eachauthentication value is configured to be used by a receiver toauthenticate the respective one of the plurality of blocks before athird block of the first data fragment is decrypted by the receiver; andencrypting, using the processing device, the first data fragment and theauthentication code.
 9. The method of claim 8, further comprisingpadding the first data fragment and the authentication code to form arecord payload having a payload length equal to a length of theplurality of blocks, wherein each block in the plurality of blocks has afixed length.
 10. The method of claim 9, further comprising storing apadding length associated with the padding as context information. 11.The method of claim 8, further comprising attaching a record header tothe encrypted first data fragment and authentication code.
 12. A methodfor performing decryption and authentication using a processor, themethod comprising: decrypting a first block in a record comprising aplurality of encrypted blocks; deriving, using context informationattached to the record, an authentication value associated with thefirst block; performing an authentication operation on the first block,using the authentication value, before a second block is decrypted; andsimultaneously decrypting and authenticating the second block and eachof a plurality of additional blocks in the record, using a plurality ofadditional authentication values, wherein each additional authenticationvalue is associated with a respective one of the each additional blocks.13. The method of claim 12, wherein an authentication code associatedwith the entire record comprises the authentication value and eachadditional authentication value.
 14. The method of claim 13, furthercomprising determining that an error has occurred if the authenticationcode does not correspond with the authentication value and theadditional authentication values.
 15. The method of claim 13, whereinthe context information comprises a padding length.
 16. A system,comprising: cryptographic circuitry configured to: receive a recordcomprising a plurality of encrypted blocks, decrypt a first block in therecord, the first block including a padding length, determine a datalength of the record using the padding length, and decrypt a secondblock in the record; and authentication circuitry configured to: derivean authentication value, associated with the second block, using thedata length, and perform an authentication operation on the secondblock, using the authentication value and the data length, before athird block in the record is decrypted.
 17. The system of claim 16,wherein the authentication circuitry is further configured to:simultaneously decrypt the second block and each of a plurality ofadditional blocks in the record; and simultaneously authenticate thesecond block and each of the plurality of additional blocks in therecord, using a plurality of additional authentication values, whereineach additional authentication value is associated with a respective oneof the additional blocks.
 18. The system of claim 17, wherein theauthentication circuitry is further configured to: determine whether anauthentication code associated with the entire record corresponds withthe authentication value and the additional authentication values. 19.The method of claim 1, wherein decrypting the second block in the recordcomprises: decrypting the second block in the record using a cipherblock chaining decryption algorithm.
 20. The method of claim 1, whereindecrypting the second block in the record further comprises: decryptingthe second block using information obtained during decryption of thefirst block in the record.